1. Field of the Invention
This invention relates to computer networking. More particularly, the invention relates to a forwarding database of a lookup table that is bifurcated into a pre-determined number of sub-databases of pre-determined size, each of which can be selected using a pointer table that chooses the sub-database of interest by performing a longest matching search on spear prefixes stored in the pointer table.
2. Description of the Related Art
The following descriptions and examples are not admitted to be conventional by virtue of their inclusion within this section.
Computer networking is generally recognized as the communication of packets across an interconnected network of computers. One objective of networking is to quickly forward the packets from a source to a destination. Thus, within the network itself may be one or more forwarding devices, herein interchangeably referred to as gateways, bridges, switches, or routers.
A forwarding device typically includes a lookup table. An incoming address can be compared to prefix entries stored within the lookup table. If a match occurs, then the associated packet of information is sent to an appropriate port of the forwarding device. As links of the network change, routing protocols exchange information among the forwarding devices to change the prefix entries within the corresponding lookup tables. This change will modify not only the prefixes within the lookup table, but also the next-hop identifiers pointed to by those prefixes. Thus, routing through the forwarding devices can be changed dynamically as links go down and come back up in various parts of the Internet or Intranet.
Internet Protocol (IP) addresses associated with a packet generally comprise a network field and a host field. The number of bits dedicated to the network and host fields can change in a class-based Internet addressing architecture. With the advent of a classless addressing architecture, referred to as Classless Inter-Domain Routing (CIDR), the boundary between the network field and the host field can vary. In addition to class and classless addressing architectures, there are currently several Internet Protocol versions of IP addressing. For instance, IP version 4 (IPv4) uses a 32-bit addressing prefix, whereas IP version 6 (IPv6) uses a 128-bit addressing prefix. If, for example, IPv4 addressing is used, then the forwarding device might only consider the first 8, 16 or 24 bits of the 32-bit addressing field in determining the next hop.
A popular way to determine the next hop is to use a technique known as longest-matching prefix. In this technique, a 32-bit IP address of, for example, 192.2.8.64 is compared against a prefix entry (hereinafter, “prefix”) within the lookup table. The prefix 192.2.0.0/16 has a longer matching prefix than prefix 192.0.0.0/8. This is due primarily to the prefix length in the former being 16 bits, and the prefix length in the latter being only 8 bits. The forwarding device will then consider the first two bytes of 192.2* when determining the next hop address at which to send the packet.
There are many ways to perform a longest-matching prefix comparison. For example, pointers or hashes may be used. A first few bits of a binary sequence can be stored as a pointer within a table. Each pointer entry will not only keep track of the prefixes within that pointer, but also will point to subsequent binary entries needed to complete the longest prefix match. While pointers will point to possibly hundreds of prefixes within sub-databases, many sub-databases are empty or sparse of any matching to incoming addresses. Dividing a database of prefixes using precursor pointers, while heuristic, does not therefore assure that the databases are optimally divided. Moreover, this conventional technique does not provide any worst-case guarantees on a lookup performance.
Another technique used to divide a database may involve use of a tree or trie. There are many different tree configurations. A simple tree is often referred to as a binary tree, with more complex trees being compressed forms of the binary tree. To search for an address within a tree, the search begins at a root node. Extending from the root node, a “1” pointer or a “0” pointer is followed to the next node, or binary bit position, within the tree. If, for example, the address begins with 001*, then the search begins at the root and proceeds downward to each vertex node, beginning along the “0” branch pointer to the next “0” branch pointer, and finally to the “1” branch pointer. The search will continue until a leaf node is reached or a failure occurs. The binary tree can be compressed to enhance the search operation. A Patricia tree is one form of compression used to shorten the length of a branch to having relatively few leaf nodes.
A disadvantage of the techniques mentioned above is that they do not provide any bounds on the size of the sub-database extending out of any pointer. This makes it difficult to provision a given amount of storage on any sub-database, and likewise does not provide any guarantees on power or speed of lookup (beyond the trivial worst-case guarantees on looking up the entire sub-database).
A search could be more optimally implemented if the prefixes within each node or searchable sub-databases are more optimally apportioned. A need, therefore, exists in configuring a special form of searchable database using “spear prefixes” that act as pointers when searched, to point only to the sub-database of interest. The desired apportionment involves placing bounds on the number of prefixes within each sub-database, and bounds on the number of sub-databases within the lookup table. By controlling the number of sub-databases and the sizes of the sub-databases, lookup operations are more deterministic, and worst-case lookup times can be guaranteed. Moreover, the bounded number of sub-databases can be more optimally apportioned to a physical device, such as a memory, with dedicated portions of the memory sized to accommodate a corresponding sub-database. This will lessen the power consumption of the lookup operation since only one sub-database need be accessed during a particular lookup.